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NOTICES 

When  Government  drawings,  specifications,  or  other  data  are  used  for  any 
purpose  other  than  in  connection  with  a  definitely  related  Government 
procurement  operation,  the  United  States  Government  thereby  incurs  no 
responsibility  nor  any  obligation  whatsoever;  and  the  fact  that  the 
Government  may  have  formulated,  furnished,  or  in  any  way  supplied  the 
said  drawings,  specifications,  or  other  data,  is  not  to  be  regarded  by 
implication  or  otherwise  as  in  any  manner  licensing  the  holder  or  any 
other  person  or  corporation,  or  conveying  any  rights  or  permission  to 
manufacture,  use,  or  sell  any  patented  invention  that  may  in  anv  way  be 
related  thereto. 

This  report  has  been  reviewed  by  the  Office  of  Public  Affairs  (ASD/PA) 
and  is  releasable  to  the  National  Technical  Information  Service  (NTIS). 
At  NTIS,  it  will  be  available  to  the  general  public,  including  foreign 
nations. 

This  technical  report  has  been  reviewed  and  is  approved  for  publication. 
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FOREWORD 


This  Task  IV  final  report  covers  the  work  performed  under  Air  Force 
Contract  <F33615-80-C-5109,  "ICAM  Architecture,  Part  III."  This  contract 
is  sponsored  by  the  Computer  Integrated  Manufacturing  Branch, 
Manufacturing  Technology  Division,  Materials  Laboratory,  Air  Force  Wright 
Aeronautical  Laboratories,  Air  Force  Systems  Command,  Wright-Patterson 
Air  Force  Base,  Ohio,  45433.  This  program  is  being  administered  under 
the  technical  direction  of  Capt.  Richard  R.  Preston. 

The  coalition  is  comprised  of  four  (4)  participating  companies  with 
SofTech  Corporation  as  the  prime  contractor.  Ms.  B.R.  Davis  is  the 
SofTech  Program  Manager.  The  other  participating  coalition  members  are 
listed  below: 

0.  Appleton  Company  Chuck  Martin 

Rockwell,  International  Richard  Heine 

Vought  A1  Reingold 

Downey  and  Small  A1  Small 

Grumman  Barnett  Frumkin 
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SECTION  1 
INTRODUCTION 


1.1  Pro.ject  Description 

The  U.S.  Air  Force  objectives  are  to  reduce  aerospace  system  costs 
by  increasing  productivity  in  aerospace  manufacturing. 

The  ICAM  Architecture  has  been  identified  as  the  means  by  which 
both  government  and  industry  could  better  understand  the  present 
manufacturing  process,  could  represent  predicted  future  operations,  and 
could  manage  the  changes  which  would  occur  in  business  and  technology. 

The  first  goal  of  the  Architecture  Part  I  Program  was  to  record  and 
present  a  common  understanding  of  the  aerospace  manufacturing  process  by 
displaying  its  functions  and  their  relationships.  This  was  accomplished 
using  the  IDEF0  technique  of  function  modeling. 

The  overall  objective  of  the  Architecture  Part  II  project  was  to 
utilize  and  expand  upon  the  baseline  manufacturing  function  model 
developed  in  Part  I. 

The  current  ICAM  Architecture,  Part  III,  Project  Priority  1104,  was 
initiated  to  maintain  and  update  the  existing  architecture,  as  well  as  to 
establish  the  transfer  of  technology  gained  from  Architecture  development. 

The  most  immediate  objective  was  to  make  known  the  architecture 
concepts  and  methods  to  organizations  engaged  in  technology  modernization. 

In  order  to  best  meet  the  needs  of  the  ICAM  program,  the 
architecture  has  been  expanded  through  subsystem  integration  in  support 
of  the  Integrated  Sheet  Metal  Center. 

The  Part  III  (1104)  Program  has  continued,  therefore,  to  upgrade 
and  expand  the  architecture  in  accordance  with  feedback  from  its  users. 

1.2  Scope 

The  effort  described  herein  focused  on  composite  models  of  the 
design  and  manufacture  of  aerospace  products.  The  contract  called  for 
two  types  of  relationship  with  subsystem  development:  the  scoping  of 
subsystems  and  the  later  integration  of  subsystem  "AS  IS"  models  into  the 
relevant  industry  composite  models.  The  effort  was  unrelated  to  actual 
subsystem  development.  The  effort  did  not  extend  into  the  "TO  BE" 
concept  arena.  A  continuing  effort  to  upgrade  the  overall  models  of  the 
aerospace  industry  was,  however,  undertaken. 
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During  the  course  of  this  contract,  a  concurrent  project  priority 
was  examining  system  engineering  methods.  This  report,  therefore,  deals 
with  procedures  only  insofar  as  they  were  needed  to  meet  the  immediate 
needs  of  model  maintenance,  subsystem  scoping,  and  model  integration. 

1.3  Background 

The  Integrated  Computer  Aided  Manufacturing  (ICAM)  program  has  as 
its  objective  the  improvement  of  productivity  in  the  aerospace 
manufacturing  sectors  of  American  industry.  It  is  directed  toward 
improving  productivity  through  the  systematic  application  of  computer 
technology  in  the  design  and  manufacturing  environment.  This  approach  is 
not  only  ambitious  but  is  also  realistic  in  that  it  stresses  the 
development  of  computer  aided  design  and  manufacturing  capabilities.  The 
integration  of  these  computer  aids  into  the  design  and  manufacturing 
environment  and  among  themselves  will  ultimately  signal  the  success  of 
the  ICAM  program. 

A  key  to  the  achievement  of  this  goal  is  the  development  of  the 
ICAM  Definition  (IDEF)  Methods  and  the  ICAM  composite  models  of  design 
and  manufacturing.  The  ICAM  Definition  Methods  are  a  family  of 
techniques  through  which  analysts  and  laymen  explore  and  discuss  the 
nature  of  design  and  manufacturing  systems.  These  techniques,  developed 
for  the  ICAM  program,  provide  a  means  of  studying,  recording,  and 
communicating  the  inherent  requirements  and  realities  of  the  aerospace 
manufacturing  environment.  They  are  equally  effective  and  valuable  in 
many  other  manufacturing  and  non-manufacturing  environments. 

There  are  three  ICAM  Definition  Methods:  IDEFjD-Function  Modeling; 
IDEFl-Information  Modeling;  and  IDEF2-Dynamics  Modeling.  A  manufacturing 
system  is  described  and  studied  through  the  application  of  all  three 
techniques. 

The  ICAM  composite  models  of  manufacturing,  or  architectures, 
records  a  "consensus  view"  of  what  manufacturing  is  and  how  it  operates. 
Composite  architectures  are  presented  in  two  forms:  the  "AS  IS" 
form-representing  the  way  in  which  manufacturing  is  currently 
accomplished;  and  the  "TO  8E"  form-representing  the  way  in  which 
manufacturing  will  be  accomplished  with  computer  aids  in  place. 

Volumes  III,  IV,  V,  VI,  of  this  report  present  updated  IDEFl  and 
IDEF0  models  of  design  and  manufacturing. 

These  models  are  presented  in  their  current  state  of  development. 

It  is  expected  that  refinements  will  continually  be  made  to  the  models  as 
a  result  of  their  use.  The  vast  amount  of  information  which  they  contain 
make  them  impossible  to  comprehend  by  cursory  examination.  A  tremendous 
effort  has  gone  into  the  preparation  of  the  models  which  are  the  end 
result  of  this  project.  Many  stages  of  critique,  validation,  and 
checking  have  been  invested  to  make  sure  that  the  published  models  are  as 
complete,  readable,  consistent,  and  correct  as  possible. 
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As  prime  contractor,  SofTech  subcontracted  the  development  of  the 
integration  procedure  for  IDEF1  to  DACOM.  Rockwell  International  and 
Vought  Corporation  participated  actively  in  the  development  and  testing 
of  integration  and  arrow  tracing  procedures  for  IDEF0. 

Architecture  Process 


The  necessary  first  step  in  increasing  design  and  manufacturing 
productivity  is  to  understand  current  design  and  manufacturing  practice 
precisely  and  to  record  this  understanding  concisely.  This  development 
of  understanding  has  two  main  phases: 

•  Study  specific  company  design 

■  Evolve  a  composite  understanding 

Factory  View 

Understanding  of  the  current  manufacturing  design  process  must  be 
based  on  the  detailed  factual  informaton  which  describes  this  process  in 
those  companies  which  successfully  produce  aerospace  products.  This  has 
been  called  "Factory  View"  information.  The  Factory  View  of 
manufacturing  and  design  is  different  for  each  company,  for  each  division 
of  each  plant  within  a  company,  and  even  somewhat  different  for  each 
organization  and  each  individual  within  each  plant. 

Composite  View 

One  objective  of  ICAM  is  to  develop  improvements  in  the  design  and 
manufacturing  process  which  will  be  broadly  applicable  across  the  whole 
aerosDace  industry.  In  order  to  do  this,  it  is  necessary  to  have  some 
understanding  of  "generic  design  and  manufacturing  practice."  Such  an 
understanding  emphasizes  the  essential  information,  information  flow, 
functions,  and  material  flow  necessary  to  all  design  and  manufacturing 
processes,  while  deemphasizing  the  differences  of  organization  and 
terminology  among  the  various  factory  views. 

The  models  representing  this  aggregate  understanding  are  called  the 
"Composite  View"  of  design.  The  composite  view  models  presented  in  this 
report  depict  design  and  manufacturing  as  they  exist  today  in  the  form  of 
functions  and  information  models.  The  composite  view  of  the  existing 
functions  and  information  occuring  in  design  which  has  been  produced  in 
this  project  emphasize  the  technical  aspects  of  current  practice  for  the 
production  of  a  single,  new  major  aerospace  product,  such  as  an  airplane. 

Sections  3  and  5  of  this  volume  document  the  procedures  for 
creating  composite  views  by  integrating  factory  view  models  into  the 
composite.  Section  3  discusses  integration  of  IDEF0  models.  Section  5 
discusses  integration  of  IDEF1  models.  Section  4  is  an  adjunct  of 
Section  3  which  deals  in  particular  with  improving  the  quality  of 
composite  IOEF0  models. 
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Architecture  Validation 


From  the  first  week  of  the  project,  a  constant  process  of  review 
guides  the  development  of  the  architecture.  Each  version  of  the 
architecture  is  distributed  to  the  coalition  members  for  comment.  These 
versions  receive  a  "Working"  status  meaning  the  architecture  is 
undergoing  change  within  the  group  responsible  for  its  develooment.  The 
comments  cause  changes  ranging  from  complete  restructuring  of  various 
levels  of  architecture  to  clarification  of  individual  words  used  in 
detailing  lower  levels. 

This  process  of  revise,  review,  revise  continues  throughout  the 
building  of  the  model.  When  the  coalition  decides  that  the  model,  or 
portions  of  it,  are  ready  for  industry  review,  the  status  is  changed  to 
"Ora ft." 

Ever'  6  months  throughout  the  project,  an  Industry  Review  Meeting 
is  held.  The  Industry  Reviewers  represent  various  manufacturing 
companies.  They  review  the  "Draft"  version  of  the  models  to  insure  that 
they  are  representative  of  design  and  manufacturing  as  a  whole.  Portions 
of  the  model  that  receive  a  consensus  of  approval  are  marked 
"Recommended."  This  signifies  that  their  content  is  recommended  for  Air 
Force  acceptance.  Portions  that  do  not  receive  consensus  remain  at 
"Draft"  status  and  receive  further  review  and  revision. 
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SECTION  2 
EXECUTIVE  SUMMARY 


2.1  Participants 

This  program  was  administered  under  the  technical  direction  of 
Captains  Steven  R.  LeClair  and  Richard  R.  Preston. 

The  Coalition  of  participating  companies  was  lead  by  SofTech,  Inc. 
as  the  prime  contractor.  Ms.  B.R.  Davis  was  the  SofTech  Program 
Manager.  Other  participating  coalition  members  were: 


0.  Appleton  Company 
Rockwell,  International 
Vought 

Downey  and  Small  Associates 
Grumman 


Chuck  Martin 
Richard  Heine 
A1  Reingold 
A1  Small 
Barnett  Frumkin 


2.2  Summarized  Accomplishments 

Architecture  Part  III  was  responsible  for  four  (4)  architecture 
models:  an  IDEF0  model  and  an  IDEF1  model  for  both  Design  and 
Manufacture.  The  level  and  type  of  activity  differed  greatly  among  the 
models.  The  accomplishments  are  summarized  in  tabular  form  on  the  next 
two  pages. 
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SECTION  3 

PROJECT  ACCOMPLISHMENTS 


This  report  covers  an  original  firm  program  and  an  option  program. 
The  firm  program  was  carried  out  from  30  September  1980  through  30  June 
1981.  The  option  program  was  carried  out  from  1  July  1981  through 
29  October  1982.  This  section  surveys  the  accomplishments  of  both 
programs. 

The  structure  of  this  section  is  based  on  the  Contract  Work 
Breakdown  Structures  (CWBS)  of  the  two  programs.  Sections  3.1  through 
3.4  cover  the  firm  program.  Sections  3.5  through  3.9  present  the 
accomplishments  of  the  option  program. 

3.1  Assume  Maintenance  of  "AS  IS"  IDEF0  Models  (Firm  Program) 

The  1104  Architecture  Part  III  Program  was  primarily  a  maintenance 
effort  to  enhance  the  "AS  IS"  MGF0,  1  and  DES0,  1  Models  to  meet  the 
needs  of  its  users. 

The  program's  most  immediate  goal  was  to  make  known  to  U.S. 
industry  the  architecture,  its  concepts  and  methods  to  enable  the 
successful  implementation  of  technology  modernization. 

This  work  of  refining  and  extending  the  composite  architecture 
provides  the  baseline  from  which  the  "TO  BE"  architecture  can  be 
developed  and  against  which  the  subsystems  being  proposed  can  be  compared. 

During  the  Firm  Program,  the  coalition  placed  emphasis  on 
maintaining  the  architecture  by  scoping  subsystems  and  extending  the 
architecture  through  the  integration  of  the  Manufacturing  Cost/Design 
Guide  (MCDG).  In  addition,  a  common  ICAM  glossary  was  initiated,  which 
will  aid  future  integration  between  function  and  information  models.  The 
glossary  effort  is  reviewed  in  Section  3.3.2.  Figure  3-1  summarizes  the 
efforts  and  results  of  the  firm  program. 
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TASK 

RESULT 

SIGNIFICANCE 

Scoping 

5501  -  IPS 

•  Agreement  Reached 

•  Provides  Independent 
Agreement  on  Project 
Scope 

6201  -  ICENT 

•  General  Agreement 

Although  Clarification 
Requested 

3101  -  C8IS 

•  Material  Not  Available 
Also  Methodology 
Shortcomings 

Integration 

| 

A 503  -  MCDG 

•  Integration  Completed 

•  Provides  Verification 
and  Validation 

•  Extends  the 
Architecture 

Figure  3-1 
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3.1.1  Scope  Subsystem,  6201 


Scoping  of  Project  6201  (ICENT)  took  place  on  January  14,  1981  in 
Dayton,  Ohio. 

The  scope  of  Project  6201  was  presented  by  G.E. 

The  Integration  Team  agreed  with  the  inclusion  of  the  nodes 
presented.  It  did,  however,  question  the  exclusion  of  two  nodes  which 
the  Integration  Team  felt  should  be  wholly  or  partially  included  within 
the  scope  of  the  ICENT.  Other  questions  raised  by  the  Integration  Team 
dealt  with  interpretation  of  specific  arrows. 

3.1.2  Scope  Subsystem,  5501 

Scoping  of  Project  5501  (IPS)  took  place  on  January  14,  1981  in 
Dayton,  Ohio.  G.E.'s  concept  of  the  scope  of  the  IPS  was  presented, 
reviewed  and  accepted. 

3.1.3  Integrate  Subsystem,  MCDG 


The  Option  III  -  Revised  Integration  Procedure  (October  1980, 

WPAFB,  Dayton,  OH)  was  used  to  identify  and  clarify  how  each  of  the  MCDG0 
lowest  level  functions  supports  one  or  more  of  the  DES0  functions 
(through  Step  2  of  the  Integration  Procedure).  Because  of  the  magnitude 
of  effort  required  to  perform  the  complete  integration  as  delineated  in 
the  Integration  Procedure,  the  integration  of  the  MCOG0  subsystem  into 
the  DES0  system  has  been  completed  only  through  integration 
clarification.  Specifically,  the  integration  has  not  been  completed  at 
this  time  for  the  Integration  Communication  Analysis  and  the  Exceptions 
Reporting. 

The  following  advantages  were  derived  from  integrating  the  MCDG0 
subsystem  into  the  OES0  composite  model: 

•  Integration  to  illustrate  the  MCOG0  subsystem  support  to  the 
DES0  system  functions, 

•  Documentation  for  use  in  determining  how  individual  company 
operations  (functions)  might  use  the  MCDG0  model  to  support 
design  activities, 

•  Documentation  for  use  as  a  training  vehicle  during  future 
MCDG0  implementation  and  acceptance  by  designers, 
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•  Documentation  for  determination  of  where  further 
decomposition  in  either  the  MCDG0  or  DES0  models  might  be 
required, 

•  Basis  for  the  description  of  the  interface  of  the  MCDG0 
subsystem  and  other  "TO  BE"  subsystems, 

•  Integration  experience  for  use  by  in-house  personnel  in 
MCDG0  implementation,  other  integration  projects, 
integration,  or  cross-integration  over  other  ICAM  systems/ 
subsystems. 

These  results  were  reviewed  and  accepted  by  industry  at  the 
industry  review  held  June  9  through  11,  1981. 


3.1.4  Arrow  Trace 


Throughout  the  firm  program,  a  careful  review  of  the  arrows  in  MFG0 
continued.  This  task  involved  following  arrows  through  levels  of  the 
model  (via  ICOM  codes)  and  through  both  branching  and  joining  of  arrows. 
The  object  of  this  "trace"  procedure  was  to  ensure  consistency  and 
meaning  of  the  arrow  from  source  to  target  destination.  This  effort 
contributed  to  the  glossary  effort  (which  is  discussed  next)  and  to 
modification  of  the  model  at  many  points. 

The  arrow  trace  procedure  as  refined  by  this  program  is  presented 
in  full  in  Volume  II  of  this  report. 

3.2  Establish  DES1  (Firm  Program) 

The  DESIGN1  project  coalition  members  were  the  Vought  Aircraft 
Corporation,  the  Grumman  Aerospace  Corporation,  and  the  0.  Appleton 
Company  (DACOM).  DACOM  was  assigned  the  modeler's  position  in  the 
project,  with  Vought  and  Grumman  providing  expert  source  information  and 
review  commentary.  The  DESIGN1  project  management  was  under  the 
direction  of  the  SofTech  program  manager  for  Project  1104. 

After  a  meeting  to  set  the  Scope  and  Context  for  the  development  of 
the  0ES1  model,  Vought  and  Grummah  began  to  gather  the  targeted  source 
materials.  The  materials  were  sent  to  DACOM  which  prepared  the  Source 
Material  Log  and  the  Source  Data  List. 

It  was  determined  the  DES1  Information  Model  would  concern  itself 
only  with  the  information  that  passed  through  the  release  function  into 
manufacturing.  All  other  information  was  considered  to  be  outside  tie 
Scope  and  Context. 
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The  modeling  effort  required  considerable  iteration.  For  example, 
as  a  result  of  one  meeting  the  number  of  Entity  Classes  contained  in  the 
relation  matrix  was  pared  from  53  to  16.  Close  to  one  hundred 
Alternative  Diagrams  were  put  together  and  distributed  for  review.  The 
collection  of  entity  classes  again  grew  to  nearly  50.  Definitions  were 
prepared;  the  relation  matrix  was  updated;  and  the  preliminary  diagrams 
for  these  50  entity  classes  were  put  together.  Function  Views  were  built 
along  with  the  Entity  Class  Definitions,  Entity  Class  Diagrams,  and  Key 
Attribute  Class  Definitions. 

The  model  was  completed  through  phase  3.X;  that  is,  the  Key 
Attribute  Classes  were  assigned  and  some  Non-Key  Attribute  Classes  were 
populated. 

The  model  was  reviewed  at  the  Industry  Review  Meeting  June  9-11, 
1981.  Besides  the  DES1  model,  the  effort  produced  proposals  for  making 
future  efforts  of  this  type  more  productive.  These  proposals  are 
documented  in  Interim  Technical  Report,  ITR110310003U,  "ICAM 
Architecture,  Part  III,"  October,  1981  (period  01  July,  1981  -  30 
Septemher,  1981). 

3.2.1  Architecture  Assessment 

The  first  coalition  working  meeting  was  held  during  the  first  week 
of  December,  1980.  The  Scope  and  Context  for  DES1  were  established,  thus 
producing  the  effort's  first  kit.  The  meeting  also  established  plans  for 
initiating  the  collection  of  the  required  data  set.  It  was  recognized 
that  an  information  model  representing  all  aspects  of  design  could  not  be 
developed  in  the  time  available.  Therefore,  the  areas  in  which  the 
information  is  transferred  from  Design  to  Manufacturing  was  chosen  as 
being  of  primary  interest.  The  results  of  this  scoping  were  formalized 
in  a  Phase  Zero  Scope  and  Context  kit. 

Later,  experience  was  to  show  that  even  greater  accuracy  and 
clarity  should  be  sought  in  model  scope  and  context  definitions.  It  was 
found  that  many  of  the  pieces  of  material  that  were  initially  collected 
were  disposed  of  because  they  did  not  fall  within  the  scope  and  context. 
Also,  many  of  the  original  entity  classes  were  eliminated  because  they 
fell  outside  the  scope  and  context. 

There  was  difficulty  with  the  establishment  of  a  firm  scope  and 
context  because  the  design  function  can  and  does  produce  many  and  varied 
products.  For  example,  design  obviously  produces  detailed  design 
drawings  but  also  produces  changes  to  drawings,  changes  in  the  manner  of 
material  references,  changes  in  the  details  of  dimensioning,  changes  in 
the  application  of  an  engineering  procedure  and  changes  in  the  routine 
for  release  of  such  drawings.  Finally,  it  was  determined  that  the  DES1 
Information  Model  would  concern  itself  only  with  the  information  that 
passed  through  the  release  function  into  manufacturing. 
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3.2.2  Collect  Data 


The  data  required  to  build  the  DES1  model  was  collected  initially 
by  Vought  and  Grumman.  The  data  collected  was  later  supplemented  by 
contributions  from  industry  during  Industry  Review  meetings. 

3.2.3  Build  Factory  View 

Factory  views  extended  only  through  the  data  collection  phase.  The 
following  "conventions"  were  employed  in  the  conduct  of  the  1104-DES1 
Information  Modeling  efforts. 

•  Two  separate  SOURCE  MATERIAL  LOGS  were  maintained.  The 
Vought  Source  Material  was  preceded  by  a  "VSM."  The  Grumman 
Source  Material  was  preceded  by  a  "GSM." 

•  Two  Separate  SOURCE  DATA  LISTS  were  maintained.  In  this 
situation  the  coding  separated  and  identified  source  data  - 
"VSD"  and  "GSO"  -  for  Vought  and  Grumman  respectively. 

3.2.4  Builo  Composite  View 

DES1  was  developed  to  the  point  of  having  eighty  (80)  entity 
classes  related  only  by  specific  relation  classes.  (There  are  no 
many-to-many  relation  classes).  All  entity  class  have  had  key  classes 
assigned  and  some  further  populating  with  attribute  classes  has  been 
completed.  The  entity  classes,  however,  are  not  fully  populated.  This 
level  of  development  is  sometimes  referred  to  as  phase  3.X.  That  is, 
phase  4  of  the  development  cycle  has  not  been  completed. 

The  DES1  model  is  presented  in  Volume  IV  of  this  final  report. 

3.3  Assume  Maintenance  of  "AS  IS"  IOEF1  Models  (Firm  Period) 


IDEFl  maintenance  during  the  firm  period  included  updating  of  MFG1, 
an  analysis  of  the  IDEFl  model  of  MCMM  (MCMM1)  and  work  on  an  integrated 
MFG0/MFG1  Glossary. 

3.3.1  Assume  Maintenance  of  "AS  IS  MFG1  (Firm  Program) 

As  a  result  of  a  review  meeting  held  in  October,  1980,  the  Task  IV 
coalition  had  comments  calling  for  changes  to  103  entity  classes  of  the 
298  entity  classes  in  the  MGF1  model.  Since  a  comment  on  any  entity 
class  could  lead  to  a  requirement  to  change  not  only  the  entity  class 
itself  but  also  all  related  relation  classes,  key  classes  and  attribute 
classes,  it  was  felt  that  the  entire  task  could  not  be  accomplished 
during  the  firm  period. 

A  weighting  procedure,  therefore,  was  developed  to  select  the 
fourteen  (14)  most  critical  entity  classes  with  which  to  deal.  Changes 
for  review  involving  these  entity  classes  were  completed  prior  to  the 
final  industry  review  meeting. 
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3.3.2  MCMMl  Analysis 

An  analysis  of  an  MCMM  IDEF1  model  was  conducted  to  determine  the 
feasibility  of  integrating  that  model  with  MFG1.  The  analysis 
established  that  fifteen  (15)  of  the  entity  classes  used  in  the  MCMMl 
model  appeared  to  match  entity  classes  already  found  in  MFG1.  However, 
it  was  determined  that  the  following  six  (6)  entity  classes  could  not  be 
integrated  into  MFG1. 

•  Inventory  Balance  (by  Cell) 

•  Allocation  (Planned  distributions  of  specific  part  numbers 
made  on  specific  work  orders  to  specific  sales  orders) 

f  Operation  instruction 

•  Part  Protection  Comment 

•  Raw  Material 

•  Unit  of  Operator  Assignment  History. 

Other  criticisms  of  MCMMl  were  also  uncovered.  Integration  of  MCMMl  with 
MFG1  was,  therefore,  deferred  and  completed  during  the  option  phase  of 
the  program. 

3.3.3  I CAM  Glossary 

Although  the  Integrated  Glossary  was  not  initially  identified  as  an 
item  which  would  be  developed  during  this  contract,  it  was  recognized 
that  such  a  glossary  would  be  beneficial  to  the  program  in  terms  of  MFG01 
and  DES01  clarification  and  would  also  provide  a  mechanism  to  assist  in 
relating  (integrating)  the  architectures.  Such  a  glossary  had  also  been 
recommended  by  the  Industry  reviewers.  Therefore,  the  coalition  with  Air 
Force  concurrence,  recommended  working  on  reconciling  the  glossaries 
between  MFG01  and  DES01  and  disseminating  these  results  both  to  industry 
and  to  the  subsystem  contractors. 

An  Integrated  Glossary  format  was  proposed  as  the  method  by  which 
the  results  of  the  coalition's  glossary  definition  work  would  be 
presented. 

Papers  on  'Glossary  Maintenance'  and  on  the  'Conceptual  Framework 
for  Glossary'  were  written  in  order  that  the  coalition's  view  of  how  the 
glossary  relates  to  the  broader  aspects  of  the  ICAM  program  would  be 
recorded.  Establishment  of  definitions  was  commenced.  This  effort  was 
expanded  during  the  option  period.  Results  of  the  effort  are  documented 
in  Volume  VII  of  this  report. 
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3.4  Firm  Period  Validation  (Firm  Program) 


From  the  first  week  of  the  project,  a  constant  process  of  review 
guided  the  development  of  the  architecture.  Each  version  of  the 
architecture  and  procedures  was  distributed  to  the  coalition  members  for 
comment.  These  versions  received  a  "Working"  status,  meaning  the 
architecture  or  procedure  was  undergoing  change  within  the  group 
responsible  for  its  development.  The  comments  caused  changes  ranging 
from  complete  restructuring  of  various  levels  of  architecture  to 
clarification  of  individual  words  used  in  detailing  lower  levels. 

This  process  of  revision  and  review  continued  throughout  the 
building  of  the  procedures  and  architectures.  When  the  coalition  decided 
that  each  model,  or  portions  of  it  were  ready  for  industry  review,  the 
status  was  changed  to  "Ora ft". 

Every  6  months  throughout  the  project,  an  Industry  Review  Meeting 
was  held.  The  review  meeting  for  the  firm  program  was  held 
June  9  thru  11,  1981  at  Wright-Patterson  Air  Force  Base,  Ohio.  The 
Industry  Reviewers  represented  various  manufacturing  companies.  They 
reviewed  the  "Draft"  version  of  the  models  to  insure  that  they  were 
representative  of  current  practice.  Portions  of  the  model  that  received 
a  consensus  of  approval  were  marked  "Recommended."  This  signified  that 
their  content  was  recommended  for  Air  Force  acceptance.  Portions  that 
did  not  receive  consensus  remained  at  "Draft"  status. 

Each  participant  also  submitted  a  report  summarizing  his  comments. 
These  comments  were  combined  with  those  noted  during  the  meeting  to 
provide  a  basis  for  the  development  which  was  to  occur  during  the  option 
program. 

3.5  Function  Model  Maintenance  (Option  Program) 

Maintenance  of  the  function  model  during  the  option  program  was 
focused  on  five  areas;  arrow  trace,  two-way  arrow  removal,  incorporation 
of  comments  from  the  review  meeting  of  9  June  1981,  integration  of  QA0, 
and  documentation  on  MFG0  of  the  results  of  subsystem  integration. 

3.5.1  Arrow  Trace 

■  ™  ^  ■  % 

The  arrow  trace  procedure  begun  during  the  firm  period  (see  Section 
3.1.5)  was  continued.  The  close  examination  of  MFG0  required  by  this 
task  produced  a  large  body  of  suggested  changes.  These  changes  varied 
greatly  and  were  categorized  by  relative  significance.  Although  no 
numerical  breakdown  of  the  amount  of  changes  in  each  category  is 
available,  suffice  it  to  say  that  there  were  many  more  minor  changes  than 
major  ones. 
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3.5.2  Remove  Two-Way  Arrows 

A  second  source  of  changes  to  MFG0  was  the  removal  of  two-way 
arrows  from  the  activity  diagrams.  The  decision  to  remove  the  2-way 
arrows  arose  from  a  concern  for  the  readibility  of  the  diagrams.  It  was 
felt  that  the  syntactic  form,  namely,  a  double-headed  arrow  with 
accompanying  dots,  did  not  clearly  portray  (in  a  graphic  sense)  the 
feedback  loop  it  represented.  The  transformation  of  the  two-way  arrows 
into  appropriate  feedback  loops  did  succeed  in  depicting  the  circular 
flow  of  data.  On  the  other  hand,  the  proliferation  of  new  arrows  added 
more  pipelines  to  some  already-crowded  diagrams.  It  was  also  noted  that, 
in  the  case  of  diagrams  with  nunerous  ICOM's,  the  deletion  of  a  two-way 
arrow  means  that  the  feedback  relationship  between  an  input  or  control 
and  an  output  would  not  be  explicit  because  other  entering  and  exiting 
ICOM's  obscure  the  relationship.  It  was  also  noted  that  the  removal  of 
the  two-way  arrows  invalidated  a  signficiant  portion  of  tine  arrow  trace 
information  (which  was  based  on  a  version  of  MFG0  having  two-way  arrows). 

The  removal  of  two-way  arrows  was  also  carried  out  for  the  IDEFp 
model  of  Design  (DES0) .  The  same  problems  as  those  of  MFG0  —  increased 
clutter  and  loss  of  reciprocal  relationship  between  initial  and  feedback 
arrows  were  noted. 

3.5.3  Incorporate  Changes  to  MFG0 

The  upgrading  of  MFG0  to  include  the  comments  from  industry  review 
was  completed  during  the  option  program. 

3.5.4  Integration  of  QA0 

The  QA  (Quality  Assurance)  model  was  integrated  into  MFG0  using  a 
revised  procedure  which  is  presented  in  Volume  II  of  this  report.  This 
required  the  modification  of  about  20  existing  diagrams  and  the  addition 
of  about  25  new  diagrams.  These  new  diagrams  are,  in  most  cases,  redrawn 
child  diagrams  from  the  QA  model.  These  additions  required  modification 
of  ICOM's  on  existing  MFG0  diagrams  and  the  QA  diagrams  that  were 
integrated  as  children  of  the  existing  MFG0  nodes. 

3.5.5  Documentation  of  Subsystem  Integration 

Another  source  of  MFG0  changes  was  the  addition  of  subsystem 
support  arrows.  These  appear  as  "mechanisms"  that  alert  the  reader  to 
subsystem  support  roles.  The  subsystems  incorporated  into  the 
architecture  are  SMC  (Sheet  Metal  Center),  MCMM  (Manufacturing  Control 
and  Material  Management)  and  QA  (Quality  Assurance).  The  mechanism 
arrows  are  labeled  "subsystem"  where  more  than  one  subsystem  supports  an 
activity.  The  resulting  model  is  documented  in  Volume  V  of  this  report. 
The  procedure  involved  is  discussed  in  the  following  section. 
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3.5.6  Shortened  IDEF  Integration  Procedure 

A  procedure  for  integrating  IDEF0  models  existed  at  the  beginning 
of  the  Architecture  Part  III  effort.  The  procedure  was  used  for  most  of 
the  IDEF0  integration  discussed  herein.  However,  it  was  found  that  the 
existing  procedure  required  an  effort  at  a  level  of  detail  which  budget 
and  available  manpower  will  not  permit: 

•  Too  many  nodes  to  examine  (477  for  MCDG) 

•  Too  much  time  to  execute  detailed  comparison  (time  for  node 
estimated  at  26  hours). 

There  were  also  objections  based  on  the  fact  that  the  architecture  was 
not  updated. 

The  industry  review  also  indicated  that: 

•  Integration  (IDEF0)  should  be  simplified 

•  Integration  procedure  (IDEF0)  needs  modification  to 
facilitate  the  ease  or  recognition  of  the  relationship  of 
subsystems  to  MFG0. 

•  Validation  and  verification  of  subsystem  models  should  occur 
during  integration. 

To  meet  this  need,  a  revised  procedure  was  developed. 

Volume  II  of  this  report  defines  the  procedure  used  to  ensure  that 
subsystems  specified  using  IDEF0  can  be  integrated  into  the  composite 
architecture  of  aerospace  manufacturing  as  defined  using  IDEF0  (MFG0) . 
Such  integration  is  a  first  step  toward  the  ultimate  integration  of  the 
physical  subsystem  into  an  actual  plant  operation. 

A  system  whose  evolution  has  been  guided  by  this  procedure  will 
consist  of  functions  which  are  clearly  related  to  specified  components  of 
the  architecture  and  whose  interfaces  to  the  rest  of  the  architecture  are 
precisely  specified. 

This  document  identifies  several  stages  in  the  development  of 
subsystems  at  which  integration  checks  should  be  performed.  For  each 
stage,  a  different  degree  of  rigor  is  required.  This  procedure  defines 
in  detail  the  stage  in  which  the  "AS  IS"  subsystem  model  is  integrated  to 
the  "AS  IS"  architecture. 

The  procedure  is  a  specific  phase  in  an  integration  process  which 
is  intended  as  a  ongoing  aid  to  the  developers  and  potential  users  of 
newly  developed  subsystems. 
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The  complete  process  consists  of  three  phases: 

1.  Scoping 

2.  Integration  of  the  "AS  IS"  subsystem  model 

3.  Integration  of  the  "TO  BE"  subsystem  model 

Phase  One,  which  precedes  the  phase  discussed  in  this  procedure, 
provides  for  a  general  scoping  of  the  subsystem  developers  task.  Before 
development  of  a  new  subsystem  is  initiated,  the  nodes  in  System0  to  be 
replaced  or  supported  by  the  subsystem  are  identified.  This  list  of 
nodes  provides  the  contracting  office  and  the  developer  with  a  clear 
specification  of  the  scope  of  development  to  be  undertaken. 

The  list  of  nodes  defines  the  areas  to  be  further  documented  by  the 
developer's  "AS  IS"  model. 

The  definition  of  any  node  may  be  further  refined  by: 

•  further  detailing  of  the  node 

•  specification  of  arrows  that  are  added,  deleted,  or  changed 
in  the  context  of  the  node. 

Phase  Two,  which  the  procedure  discusses  occurs  when  the  subsystem 
developer  has  completed  an  "AS  IS"  model.  The  subsystem  developer 
specifies  a  comparison  of  functions  and  external  interfaces  between  the 
subsystem  model  and  the  "AS  IS"  System?).  The  comparison  is  not 
exhaustive,  and  discrepancies  noted  need  not  be  corrected  immenlScely. 

The  list  of  discrepancies  is  used  as  a  guide  by  the  subsystem  developer 
in  developing  his  "TO  BE"  specifications  and  by  the  integration  team  for 
review  at  the  next  level  of  integration  effort. 

In  the  final  phase,  after  this  procedure  is  completed  and  when  the 
subsystem  developer  has  completed  a  "TO  BE"  IDEF0  specification  of  his 
subsystem,  the  comparison  of  functions  and  interfaces  is  repeated  with 
greater  rigor  and  is  extended  to  an  identification  and  consideration  of 
functions  which  are  related  to,  but  not  included  in,  the  subsystem.  Such 
functions  are  considered  so  as  to  obtain  greater  precision  and  rigor  in 
the  specification  of  Subsystem?)  to  System^  interfaces.  Analysis  of  the 
interfaces  may  indicate  a  need  to  change  areas  of  the  architecture 
outside  the  subsystem  to  accommodate  revised  needs  or  outputs  resulting 
from  subsystem  installation. 

This  final  phase  uses  both  "AS  IS"  and  "TO  BE"  versions  of  System?! 
since  new  subsystems  must  meet  two  integration  criteria.  That  is,  the 
new  subsystem  must  be  useful  in  factories  as  they  exist  today  and  must 
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also  fit  smoothly  into  an  image  ("TO  BE"  model)  of  the  updated  and 
integrated  factory  of  tomorrow. 

It  is  within  this  total  integration  scenario  that  the  procedure  is 
designed  to  operate. 

Figure  3-2  shows  an  overview  of  the  total  process  just  described. 
This  illustrates  the  ultimate  purpose  and  intended  outputs  of  the  process 
of  which  this  procedure  is  a  part. 
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3 . 6  Information  Model  Maintenance 


MFG1  is  a  composite  information  model  of  the  entity  and  attribute 
classes  associated  with  the  "Manufacture  (Aerospace)  Product"  function 
model.  This  composite  view  architecture  is  representative  of  the 
majority  of  aerospace  manufacturers  in  the  United  States  and  is  not 
intended  to  represent  any  specific  company. 

The  model  which  is  presented  in  Volume  IV  of  this  report  extends 
and  supercedes  Volume  IX  -  Composite  Information  Model  of  "Manufacture 
Product"  (MFG1)  published  in  June  of  1981  as  part  of  the  ICAM 
Architecture  Part  II  Project  Priority  1102. 

The  process  of  developing  an  IDEF1  model  involves  subdividing  the 
model  into  nodes  and  the  modeling  effort  in  phases. 

A  node  represents,  everything  that  is  known  in  any  given  phase  about 
a  particular  aggregate  of  information  called  an  entity  class.  Each  node 
is  assigned  a  (model  unique)  node  number  which  is  found  in  the  lower 
left-hand  corner  of  each  model  diagram.  Each  node  individually  passes 
through  each  phase  of  the  model  building  effort.  As  such,  the  model  does 
not  move  en  masse  from  phase  to  phase,  but  rather  moves  as  individual 
nodes,  one  at  a  time.  It  is  common  during  model  development  to  find 
nodes  in  each  of  the  phases. 

There  are  five  phases  in  IDEF1  development.  The  first  phase,  Phase 
0,  establishes  the  context  of  the  model  to  be  produced  and  the  purpose 
and  viewpoint  of  the  model. 

Phase  1  involves  the  establishment  of  entity  classes,  their  names, 
and  their  definitions.  This  is  the  true  starting  point  of  the  model 
proper.  Each  node  that  starts  here  or  is  created  later  must  be 
documented  in  Phase  1. 

In  Phase  2,  entity  classes  are  paired  according  to  the  observed 
associations  between  them.  These  associations  are  called  relation 
classes,  and  are  also  given  names  and  definitions. 

In  phase  3,  two  very  important  transformations  take  place.  First, 
relation  classes  are  refined.  This  usually  involves  the  creation  of  new 
entity  classes  which  are  referred  back  to  Phase  1  for  incorporation. 
Second,  since  each  entity  class  is  thought  of  as  representing  many 
similar  entities,  a  distinction  is  made  by  listing  the  unique  properties 
of  each  entity  class.  These  properties  are  called  key  attribute  classes. 

Finally,  in  Phase  4,  the  remaining  attribute  classes  are 
identified,  named,  and  defined.  This  also  results  in  the  creation  of  new 
entity  classes  which  again  are  referred  back  to  Phase  1. 
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The  architecture  presented  in  this  report  is  based  on  the  1981 
version,  but  differs  from  it  in  three  ways. 

The  changes  were  intended  to: 

•  Incorporate  comments  from  industry  reviewers. 

•  Utilize  knowledge  by  development  of  IDEF1  models  for 
subsystems 

•  Promote  readability  of  the  models. 

The  industry  comments  not  incorporated  during  the  firm  program  were 
now  added  to  MFG1. 

The  compositing  effort  occurred  in  two  stages.  In  the  first  stage 
the  models  developed  in  Project  Priority  5501  Integrated  Planning  System 
and  Project  Priority  6201  Manufacturing  Control  and  Material  Management 
were  composited  into  MFG1.  This  effort  resulted  in  the  addition  of 
seventy-seven  (77)  entity  classes  (with  associated  relation  classes, 
attribute  classes,  and  key  classes)  to  MFG1.  In  addition,  the 
equivalence  of  many  other  entity  classes  within  the  three  models  was 
established. 

In  the  next  stage,  QA1,  the  IDEF1  model  of  Quality  Assurance,  was 
composited  with  MFG1.  This  resulted  in  the  addition  of  another  eight  (8) 
entity  classes  as  well  as  the  identification  of  more  equivalent  entity 
classes. 

3.6.1  Document  the  IDEF1  Integration  Procedure 

Under  this  project,  there  was  a  need  not  only  to  composite  the  MFG1 
model  and  subsystem  models,  but  to  develop  a  procedure  for  such 
compositing.  The  procedure  calls  for  phases  which  closely  parallel  the 
phases  used  to  develop  an  IDEF1  model  initially.  The  complete  procedure 
is  presented  in  Volume  II  of  this  report.  The  remainder  of  this  section 
provides  a  summary  description  of  the  integration  procedure. 

The  IDEF1  integration  procedure  is  designed  td  serve  as  a  reference 
guide  for  the  combining  of  two  or  more  IDEF1  information  models  into  a 
single  information  model.  The  concepts  used  to  facilitate  the  combining 
of  IDEF1  information  models  are  described  and  depicted  in  the  various 
examples  contained  in  Volume  II  of  this  final  report.  This  procedure  is 
designed  to  be  a  working  reference  for  the  experienced  information 
modeler. 

This  procedure  assumes  that  the  integration  modeler  has  a  working 
knowledge  of  IDEF1  information  modeling  methodology  and  has  experience  in 
building  multiple  IDEF1  information  models. 


3-15 


FTR110410000U 
8  September  1983 


The  procedure  is  based  on  two  assumptions  regarding  the  quality  of 
the  models  to  be  used  in  the  integration  process.  These  assumptions 
are:  1)  the  models  correctly  apply  the  IDEF1  methodologies,  and  2)  the 
models  accurately  reflect  the  factory  views  they  represent.  The  quality 
of  the  source  models  will  have  an  impact  on  the  ease  with  which  the 
models  can  be  integrated.  Models  which  oo  not  correctly  apply  the  IDEF1 
methodology  or  do  not  accurately  reflect  the  environments  they  represent 
can  cause  the  resulting  integrated  model  to  lack  credibility. 

The  modeler  must  also  guard  against  any  inadvertent  changes  to  the 
views  of  the  source  models,  as  a  result  of  the  Integration  process.  This 
can  occur  rather  easily  and  the  modeler  should  refer  to  the  source  models 
frequently  during  the  integration  process  to  ensure  that  the  integrateo 
model  maintains  the  source  model  views. 

The  modeling  team  should  consist  of  modelers  and  reviewers  who 
represent  the  various  source  models.  A  team  established  in  this  way  will 
provide  additional  guarantees  that  the  source  model  views  are  maintained 
in  the  integrated  model. 

In  the  course  of  integrating  ID6F1  information  models,  the  modeler 
may  find  that,  between  the  source  models  being  integrated,  there  exist  no 
common  entity  classes.  As  a  result,  ‘'bridges"  will  have  to  be  built 
between  the  models  and  new  entity  classes  will  result. 

New  entity  classes  may  also  be  created  from  resolutions  of 
discrepancies  that  arise  as  a  result  of  the  varying  views  of  the  models 
being  integrated. 

Any  number  of  IDEF1  information  models  can  be  integrated  using  this 
procedure.  However,  the  more  models  being  integrated,  the  more  involved 
the  record  keeping  becomes  to  provide  traceability  back  to  the  source 
models. 

This  procedure  utilizes  a  five-phase  approach  to  the  development  of 
an  integrated  model.  This  approach  is  consistent  with  the  five-phase 
development  of  an  IDEF1  information  model.  The  documentation  introduced 
by  this  procedure  also  parallels  the  IDEF1  information  modeling 
methodology.  The  differences,  due.  to  the  nature  of  the  integration 
process,  will  become  evident  from  the  following  discussion.  The  five 
phases  for  developing  an  integrated  model  are  as  follows: 

Phase  Zero 

Phase  Zero  documents  the  context  of  the  integrated  model.  In  this 

phase,  the  scope  of  the  integrated  model  is  defined,  its  objectives 

are  stated,  and  the  source  data  identified. 
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Phase  One 

In  Phase  One,  the  objective  is  to  identify  and  define  the  candidate 
entity  classes  to  be  used  in  the  integrated  modeling  effort. 

Phase  Two 


In  Phase  Two,  the  initial  relation  classes  between  the  candidate 
entity  classes  will  be  identified. 

Phase  Three 


In  Phase  Three,  the  key  classes  for  each  of  the  entity  classes  in 

the  integrated  model  will  be  identified  and  defined. 

Phase  Four 

In  Phase  Four,  the  integrated  model  will  be  populated  with  its 

non-key  attribute  classes. 

The  result  of  the  integration  process  will  be  a  new  model  which 
will  reflect  the  combined  views  of  all  of  the  source  models.  It  is  of 
utmost  importance  that  the  integrated  model  accurately  represent  the 
views  of  the  various  source  models  and  that  the  components  of  the  source 
models  are  identifiable  within  the  context  of  the  completed  integrated 
model.  Maintaining  this  approach  will  ensure  maximum  usability  of  the 
model  to  the  enterprise. 

3.6.2  Integrate  5501  and  6201  IDEF1  Models  with  MFG1 

The  task  of  integrating  the  IDEF1  models  from  ICENT  (6201)  and  IPS 
(5501)  with  MFG1  was  carried  out  in  two  steps. 

First,  IPS1  and  ICENT1  were  integrated  using  the  draft  IDEFl 
Integration  Procedure  previously  developed.  The  model  was  developed  to 
the  equivalent  completion  of  an  IDEFl  Phase  2.  The  results  of  this 
integration  were  presented  to  the  ICAM  Community  at  the  New  Orleans 
Review  Meeting. 

Next  the  5501  IPS/6201  ICENT  Integrated  Composite  View  (ICV)  model 
was  integrated  with  MFG1.  The  resulting  MFG1  Composite  View  reflects  the 
identification  of  attribute  classes  which  fail  the  "no  null"  and  "no 
repeat"  test,  but  are  not  refined.  This  approach  is  consistent  with  the 
development  of  the  5501  and  6201  models.  This  integration  has  expanded 
the  MFG1  model  to  include  approximately  one  hundred  entity  classes  and 
represents  a  signficant  enhancement  to  MFGl's  useability. 
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3.6.3  Incorporate  Changes  to  MFG1 

Recommended  changes  resulting  from  comments  received  during  the 
October,  1981  coalition  meeting  were  incorporated  into  MFG1.  These 
changes  were  presented  and  accepted  by  the  1104  coalition  industry 
reviewers  at  the  January,  1982  New  Orleans  Industry  Review.  The  category 
of  changes  which  were  made  are  listed  below. 

•  New  Entity  Class(es)  Required 

•  Relation  Class  Syntax  Changes 

•  New  Attribute  Class (es)  Required 

•  Key  Class  Changes 

•  Changes  to  Function  Views 

•  Relation  Class  Label  Changes 

•  Relation  Class  Definition  Changes 

3.6.4  I0EF1  Hierarchy  Study 

As  a  result  of  comments  received  from  industry,  it  was  determined 
to  conduct  a  review  of  MFG1  focusing  on  improving  the  clarity  and  utility 
of  the  model.  The  primary  objective  was  to  determine  whether  the  MFGl 
entity  classes  could  be  grouped  into  an  appropriate  hierarchy. 

After  careful  analysis,  a  decision  was  made  to  group  entity  classes 
based  ipon  MFG0  partitioning.  The  entities  were  grouped  according  to 
their  relationship  to  the  manufacturing  activities.  Thus,  entity  classes 
are  grouped  and  are  associated  with  a  given  activity  if  the  entities  they 
represent  are  used  implicitly  or  explicitly  in  an  input,  control,  or 
mechanism  of  that  activity,  or  if  they  are  produced  by  that  activity,  or 
if  they  are  used  internally  between  two  or  more  sub-activities.  Groups 
containing  large  numbers  of  entity  classes  have  been  analyzed  in  greater 
detail  and  assigned  to  smaller  groups,  associated  with  third  level 
activities.  This  effort  lead  to  a  significant  increase  in  the  number  of 
FEO's  associated  with  MFGl.  The  results  appear  in  Volume  VI  of  this 
report. 

3.7  I CAM  Glossary 

By  March  of  1982,  a  preliminary  glossary  containing  approximately 
1000  terms  had  been  established.  The  entries  represented  the  pipelines 
of  MFG0  and  the  entity  classes  and  attribute  classes  of  MFGl. 

The  coalition  reviewed  the  preliminary  MFG01  glossary  in  order  to 
identify  and  prioritize  those  aspects  needing  refinement  or  expansion. 

An  approach  was  established  for  accomplishing  these  objectives  and  the 
coalition  began  the  task  of  writing  glossary  definitions  for  the 
functions  contained  in  the  MFG0  Architecture. 
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In  addition,  the  glossary  format  established  under  the  firm  program 
was  reviewed  and  tested.  A  final  format  was  developed  which  is  shown  in 
Figures  3-3  and  3-4  along  with  definitions  and  explanations  of  the 
columns  used. 


The  results  of  this  effort  are  documented  in  Volume  VII  of  this 
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3.8  Technology  Transfer 

In  order  to  promote  the  dissemination  of  the  products  of  the  ICAM 
program,  a  series  of  presentation  materials  was  prepared.  Section  3.8.1 
lists  the  materials,  and  Section  3.8.2  provides  the  material  needed  to 
obtain  copies. 

3.8.1  Abstracts  of  Approved  Technology  Transfer  Documents  Produced  to 
Date 


1.  Technology  Transfer  Program  Task  Report  (TM  1104600Q0U) 

This  report  synopsizes  the  approach  and  development  of  the 
technology  transfer  material  as  well  as  recommendations  for 
its  future  use. 

2.  Technology  Transfer  Execution  Overview  Presentation  Manual 

(tM  1104600001m  '  ' 

This  instructor's  Presentation  Manual  contains  copies  of 
viewgraphs  and  is  designed  to  help  orient  and  educate 
executive  level  management  relative  to  the  need  for  a 
structured  approach  to  implementing  new  manufacturing 
technology,  thereby  gaining  productivity.  It  provides  an 
overview  of  the  U.S.  Air  Force's  Manufacturing  Technology 
Modernization  Program's  use  of  related  IDEF  applications, 
concepts,  and  procedures.  It  also  covers  the  use  of  ICAM 
Architecture  in  planning  and  controlling  these  Manufacturing 
Technology  Modernization  Programs  to  upgrade  the  U.S. 
industrial  base. 

3.  Transfer  Executive  Overview  "Train  the  Trainer's  (TM 
1104600002U) 


This  "Train  the  Trainer's"  Manual,  coupled  with  the  above 
Presentation  Manual,  contains  copies  of  viewgraphs  and 
supplements  for  each  viewgraph  and  is  designed  to  give  the 
instructor  maximum  efficiency  in  orienting  executive  level 
personnel.  It  employs  a  step-by-step  process,  section-by- 
section,  dealing  with  "top-down"  Manufacturing  Technology 
Modernization  planning  and  "bottom-up"  project 
implementation  concepts  and  procedures. 


This  Presentation  Manual  contains  copies  of  viewgraphs  and 
is  provided  to  help  teach  an  overview  of  the  U.S.  Air 
Force's  Technology  Modernization  (TECH  MOD)  Program's  use  of 
related  IDEF  applications,  concepts,  procedures.  It  also 
covers  the  use  of  the  resulting  architecture  and  planning  in 
controlling  these  Technology  Modernization  Programs  to 
upgrade  the  U.S.  industrial  base. 

5.  Technology  Transfer  Practitioner's  Train  the  Trainers  Manual 
(TM  11Q4600004U)  '  ” 

This  training  manual  contains  copies  of  viewgraphs  with 
narrative  supplements  for  each  viewgraph  and  is  designed  to 
give  the  instructor  maximum  efficiency  in  training 
manufacturing  personnel.  This  manual  provides  step-by-step 
process,  section-by-section,  dealing  with  the  concepts  and 
procedures  of  IDEF  Function  Modeling,  including  reading , 
authoring,  commenting  on,  and  iterating  IDEF  Function  Models. 

3.8.2  Ordering  Procedure 

Use  the  Reguest  Order  Form  presented  in  Figure  3-5  to  reguest 
copies  of  Technology  Transfer  Documents,  and  submit  to: 

ICAM  Program  Library 

AFWAL/MLTC 

Wright-Patterson  AFB,  OH  45433 

3.8.3  Develop  Graphic  Material 

To  support  and  encourage  technology  transfer,  the  program  developed 
the  following  film  reports. 

1.  Project  Priority  1104  Management  Summary  Film  Report 
(FLM110410010U) 


This  7-minute  film  highlights  objectives  and  benefits  of  the 
ICAM  architecture.  It  summarizes  the  project  achievements 
and  presents  an  outline  of  the  types  of  benefits  that  result 
from  ICAM  Architecture  applications. 
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2.  Project  Priority  1104  Complete  Motion  Picture  Film  Report 
(FLM110410020U) 

The  movie  opens  with  a  fast  visual  history  of  airplane 
manufacturing.  Comments  on  the  value  of  the  ICAM  program  to 
the  aerospace  industry  form  a  thread  which  runs  throughout 
the  entire  film.  The  film  discusses  the  IDEF  methodology, 
the  achievements  of  the  ICAM  Architecture,  Part  III  Program 
and  depicts  how  integration  is  actually  accomplished. 


3.8.4  Ordering  Procedure 


Use  the  Request  Order  Form  presented  in  Figure  3-6  to  request 
copies  of  Project  priority  1104  Film  Reports  and  submit  to: 


ICAM  Program  Library 
AFWAL/MLTC 

Wright-Patterson  AFB,  OH  45433 
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APPROVED  TECHNOLOGY  TRANSFER  DOCUMENT  REQUEST  ORDER  FORM 

Submit  document  requests  to:  ICAM  Program  Library 

AFWAL/MLTC 

Wright-Patterson,  AFB,  OH  45433 

Document  Configuration 
Management  Number 

Title  of  Document  Requested 
and  Document  Date 

Indicated  (i /) 
Document 
Requested 

TM  110460000U 

Technology  Transfer  Program  Task 
Report,  May  1982 

TM  110460001U 

Technology  Transfer  Executive 
Overview  Presentation  Manual 

May,  1982 

TM  110460002U 

Technology  Transfer  Executive 
Overview  "Train  the  Trainers" 
Manual"  May,  1982 

TM  110460003U 

Technology  Transfer  Executive 
Overview  Practitioner's 

Presentation  Manual,  May,  1982 

TM  110460004U 

Technology  Transfer  Executive 
Overview  Practitioner’s  "Train 
the  Trainers"  Manual,  May,  1982 

NAME 

TITLE 

COMPANY 

DEPARTMENT 

MAIL  CODE 

STREET  OR  P.0.  BOX 

STATE  ZIP 

PHONE  # 

INTENDED  USE:* 

PROJECT: 

*No  request  may  be  processed  without  this  information. 

Figure  3-5 
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APPROVED  FILM  DOCUMENT  REQUEST  ORDER  FORM 


Submit  document  requests  to:  ICAM  Program  Library 

AFWAL/MLTC 

Wright-Patterson,  AFB,  OH  45433 


Indicated  (i/) 

Document  Configuration 

Title  of  Document  Requested 

Document 

Management  Number 

and  Document  Date 

Requested 

FLM 1104 100 10U 

Management  Summary  Film  Report 
(7  Min.) 

FLM11041002U 

Complete  Motion  Picture  Film 
Report  (17  Min.) 

Figure  3-6 


NAME  _ _ 

TITLE  _ _ _ _ 

COMPANY  _ _ 

DEPARTMENT  _ _ 

MAIL  CODE  _ _ 

STREET  OR  P.O.  BOX  _  . 

STATE  _  ZIP  _ 

PHONE  #  _ 


INTENDED  USE:*  _ _ _ 

PROJECT: 


*No  request  may  be  processed  without  this  information 


A*, 
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3.9  Validate  Option  Work 

The  coalition  members  attended  and  participated  in  the  ICAM  sixth 
annual  Industry  Days  Conference  at  New  Orleans  from  17  through  22 
January,  1982.  A  presentation  was  made  regarding  the  objectives  and 
accomplishments  of  the  1104  Program.  The  presentation  emphasized  the 
development  and  benefits  of  the  ICAM  architecture,  as  well  as  the  effort 
being  performed  by  the  1104  Program  to  maintain  and  improve  its  use. 
with  this  same  theme,  a  booth  was  developed  which  indicated  where  and  how 
the  architecture  was  being  used  as  well  as  a  graphic  description  of  the 
Project  Priority  1104  activities  to  maintain  it. 

It  was  determined  to  be  beneficial  to  present  some  of  the  material 
developed  by  the  1104  coalition  to  non-coalition  members.  These 
materials  included  the  IDEF1  Integration  Procedure  and  the  integration  of 
IPS  (Project  Priority  5501)  and  ICENT  (Project  Priority  6201)  to  MFG1 . 
Both  the  integration  procedure  and  MFG1  which  was  presented  on  21  January 
1982  appeared  to  be  well  received  by  those  reviewers  in  attendance. 

A  final  industry  review  meeting  was  held  June  8  thru  10,  1982. 
Review  of  IDEF0  focused  on  the  removal  of  two-way  arrows  and  on  arrow 
trace  results.  Review  of  IDEF1  focused  on  the  development  of  more  useful 
FEO's  and  on  a  detailed  review  of  MFG1. 
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SECTION  4 

RECOMMENDATIONS  FOR  FUTURE  WORK 


4.1  Introduction 


The  ICAM  program  has  devoted  significant  time  and  resources  to 
developing  the  Architectures  of  Design  and  Manufacture  and  the 
methodologies  on  which  they  are  based.  The  result  can  become  a 
significant  contribution  to  the  effort  to  modernize  the  country's 
industrial  base.  The  use  of  the  architectures  and  the  methods  is  already 
widespread. 

These  recommendations  are  concerned  with  maximizing  the  future 
contribution  of  both  the  architectures  and  the  methods.  Some  of  the 
recommendations  deal  directly  with  the  question,  "How  can  these  models 
and  methods  best  serve  the  needs  of  the  Armed  Forces  and  of  American 
industry?"  Other  recommendations  deal  with  the  possible  improvements  in 
the  models  or  in  the  methodologies  on  which  they  are  based. 

It  is  hoped  that  other  armed  services,  other  industries,  and 
individual  companies  will  increasingly  utilize  the  ICAM  architectures 
directly,  or  as  prototypes  from  which  to  develop  architectures  tailored 
to  their  specific  circumstances.  Such  work  will  be  easier  and  more 
productive  if  the  lessons  learned  from  ICAM's  pioneering  efforts  are 
available  to  such  users.  This  wider  audience,  and  certainly  the  ICAM 
community,  is  the  intended  beneficiary  of  these  thoughts. 

With  this  audience  in  mind,  the  recommendations  are  divided  into 
three  sections.  Section  4.2  discusses  the  uses  of  the  models.  Section 
4.3  discusses  ways  in  which  the  methodologies,  and  their  transfer,  might 
be  improved.  Section  4.4  offers  comments  on  possible  areas  and 
directions  for  improvements  in  the  models  themselves.  Such  improvements 
might  be  carried  out  by  either  the  ICAM  program  or  by  other  users. 

4.2  Use  of  the  Architectures  After  Development 

During  the  ICAM  program,  the  architecture  has  been  used  primarily 
to  scope  subsystems  and  to.  relate  subsystem  models  to  an  overview  of  the 
aerospace  industry.  These  efforts  would  have  been  more  fruitful  if: 

1.  Integration  had  been  initiated  when  subsystem  efforts 
started,  rather  than  after  they  were  well  under  way; 

2.  Integration  had  focused  on  interfaces  rather  than  on  lists 
of  functions; 

3.  A  "TO  BE"  overview  architecture  had  been  developed; 
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4.  Integration  efforts  were  carried  out  top  down  rather  than 
bottom  up. 

5.  A  meaningful  role  in  scoping  and  integration  had  been 
developed  for  IDEF1  both  as  a  support  to  the  use  of  IDEF0 
and  as  an  independent  factor  in  the  integration  process. 

Each  of  these  recommendations  can  and  should  be  addressed  in  the 
future.  Each  of  the  recommendations  is  discussed  more  fully  in  one  of 
the  subsections  which  follow. 

4.2.1  Recommendation  1  —  Pre-Integration 

This  recommendation  is  based  on  the  thesis  that  it  is  easier  to 
build  pieces,  subsystems,  to  conform  to  an  overall  plan  than  it  is  to 
build  a  plan  which  incorporates  predeveloped  pieces.  The  architectures 
provide  the  first  step  in  developing  a  plan.  The  second  step  is  to 
define  the  way  in  which  the  architecture  is  to  be  divided  into  subsystems 
with  all  of  the  subsystems  in  mind  at  the  same  time.  These  two  steps 
provide  an  outline  in  which  each  subsystem  has  a  role  which  is  compatible 
with  the  roles  planned  for  each  of  the  other  subsystems. 

To  add  substance  to  the  outline,  still  other  steps  should  be  taken 
before  subsystem  development  begins.  These  steps  can  be  local  to  a 
specific  subsystem  and  the  subsystems  with  which  it  will  interface.  They 
include: 

a.  Specification  of  how  the  new  subsystem  will  differ  from 
existing  procedure; 

b.  Clear  and  firm  definition  of  the  interfaces  between 
subsystems; 

c.  Clear  and  firm  definition  of  each  subsystem's  authority  and 
responsibility  to  access  and  update  data. 

Steps  b  and  c  are  discussed  more  fully  as  part  of  the 
recommendations  which  follow. 

An  industrial  user,  of  course,  will  seldom  be  able  to  follow  this 
scheme  from  the  beginning.  Economics  will  dictate  that  some  of  the 
subdivision  has  already  been  defined  by  existing,  expensive,  packages 
which  would  not  be  easily  divided.  Such  packages  will  often  appear 
intact  as  part  of  the  final  overall  plan.  Their  boundaries  are  among  the 
boundaries  which  divide  the  architecture  Into  subsystems.  This  does  not 
argue,  however,  that  the  development  of  an  overall  plan  is  better  left 
until  later  when  even  more  fragmented  pieces  are  likely  to  have  been 
installed. 
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4.2.2  Recommendation  2  —  Specify  Subsystem  Interfaces 

IOEF0  is  founded  on  the  belief  that  the  "human  mind  can  understano 
any  amount  of  complexity  as  long  as  it  is  presented  in  easy-to-grasp, 
small  chunks  that  are  structured  together  to  make  the  whole."  Most 
errors  in  the  application  of  IDEF0  flow  from  a  failure  to  be  sure  that 
the  pieces  are  properly  "structured  together  to  make  the  whole." 

The  cement  used  in  the  structuring  consists  of  the  interfaces 
between  functions.  If  the  subsystem  developer  knows  what  he  will 
receive,  and  what  he  must  supply,  he  can  build  a  subsystem  which  can  be 
integrated.  That  is,  each  subsystem  will  be  designed  to  supply  those 
needs  of  other  subsystems  for  which  it  has  been  assigned  responsibility. 
But  interface  definitions  must  go  beyond  IDEF  models. 

The  interfaces  as  portrayed  by  IDEF®  and  IDEF1  are  conceptual. 
Integration  is  implemented  only  by  interfaces  completed  inthe  physical 
world.  This  requires  that,  for  each  interface  identified  in  IDEF0, 
carriers,  representation,  and  units  must  be  specified. 

For  example,  the  integration  team  might  document  the  need  for  a 
temperature  to  be  passed  from  one  subsystem  to  another.  It  would  still 
be  necessary  for  the  supplying  and  the  using  system  to  operate  on  a  set 
of  standards  such  as  Centigrade,  ASCII,  sent  by  serial  transmission  to 
some  telephone  at  1200  Baud.  If  the  receiving  system  required  instead  an 
analog  signal,  say  voltage  equal  to  degrees  Fahrenheit,  then  provision 
for  a  conversion  interface  would  be  required. 

The  same  comments  apply  if  the  interface  is  completed  by  passing  a 
transaction  or  by  leaving  the  interface  data  in  a  database  for  later 
access  by  the  using  subsystem. 

The  specification  of  such  interfaces  will,  of  course,  be  unique  to 
each  enterprise  although  generic  systems  such  as  those  developed  by  ICAM 
can  provide  a  prototype  on  which  each  enterprise  can  build. 

The  efforts  to  develop  such  specifications  will  be  even  more 
important  with  the  availability  of  networked  systems  such  as  IISS.  It 
appears  certain  that  the  type  of  information  just  discussed  must  be 
supplied  to  the  validation  tables  and  common  data  model  of  the  IISS 
before  that  system  can  provide  a  proper  testbed  for  real  world 
applications. 

4.2.3  Recommendation  3  —  "TO  BE"  Overview 


The  integration  task  must  have  two  faces  like  the  Roman  God  Janus. 
One  face  must  look  to  the  "AS  IS"  state  of  an  industry  or  an  enterprise 
since  a  new  system  must  surely  fit  into  the  existing  environment.  It 
would  be  futile  to  ask  an  enterprise  to  shut  down  for  "just  a  few  years" 
while  a  new,  all  encompassing  system  is  built  to  suit  its  needs.  Rather, 
there  must  be  a  plan  which  allows  each  new  subsystem  to  be  installed  while 
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the  enterprise  continues  to  operate.  The  other  face  of  this  Janus-like 
task  must  look  to  the  future  since  the  end  objective  is  to  build  a 
factory  of  the  future. 

The  look  to  the  future  requires  the  definition  of  a  "TO  BE" 
architecture.  Such  architecture  need  not  be  carried  to  great  detail. 
Rather,  it  should  show  the  major  pieces  of  which  the  future  system  will 
be  composed.  Special  provisions  are  required  to  show  the  role  of  support 
systems  such  as  Group  Technology  Classification  and  Coding  (GTCC).  GTCC, 
for  example,  has  local  impacts  in  such  diverse  areas  as  Design,  Process 
Planning,  and  shop  floor  layout. 

The  "TO  BE"  model  should,  of  course,  be  under  configuration  control 
since  with  use  will  come  greater  understanding  and  with  greater 
understanding  will  come  improvements.  The  "AS  IS"  model,  equally,  should 
evolve  through  successive  revisions  to  capture  planned,  and  unplanned, 
changes  as  they  occur. 

The  resolution  of  the  dichotomy  between  the  present  and  the  future 
views  will  require  a  second  level  of  planning  —  for  temporary 
interfacing  modules,  for  simultaneous  installation  of  two  or  more 
modules,  or  for  other  conversion  procedures.  A  series  of  "intermediate" 
models  showing  the  planned  phases  through  which  the  system  will  pass  will 
help  to  smooth  this  part  of  the  transition.  Again,  the  reader  should  not 
visualize  groups  of  models  each  the  size  of  MFG0.  That  would  be 
monstrous  and  unacceptable.  The  models  proposed  can  be  quite  small  and 
still  accomplish  the  intended  purpose  if  (and  only  if)  they  are 
thoughtfully  planned. 

4.2.4  Recommendation  4  —  Top  Oown  Integration 

Any  subsystem  can  be  viewed  as  a  cohesive  entity,  a  single  IDEF0 
box.  Much  confusion  about  interfaces  is  eliminated  if  only  the 
interfaces  external  to  the  box  are  examined  by  the  integrator.  Internal 
interfaces  are  the  province  of  the  subsystem  builder. 

The  analysis  of  external  interfaces  can  also  be  simplified  if  it 
proceeds  from  the  top  down.  Initially,  the  integrator  should  be  able  to 
state  the  integration  requirements  In  general  terms  relating  to  IDEF0 
pipeline  level  arrows.  Once  these  requirements  are  stated,  more  and  more 
detailed  views  of  each  pipeline  can  be  examined  in  the  architecture.  If 
the  plan  is  consistent  at  the  top  level,  the  detailed  examination,  while 
necessary,  is  likely  to  hold  few  unpleasant  surprises.  Starting  such  an 
effort  at  the  detailed  level  has  been  shown  by  the  ICAM  program  to  be 
beyond  the  resource  level  which  can  be  justified. 
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4.2.5  Recommendation  5  —  Actively  Use  IDEF1 

The  first  four  recommendations  have  mentioned  the  role  of 
information  as  interface  without  specific  reference  to  IDEF1.  This 
section  addresses  the  role  of  IDEF1,  and  the  extensive  development  work 
which  appears  to  be  needed  to  fully  utilize  its  capabilities. 

First,  the  IDEF1  models  need  to  be  annotated  to  show  responsibility 
and  authority  to  update  and  to  access  each  piece  of  the  model,  preferably 
after  extending  the  models  to  the  attribute  class  level. 

Next,  or  in  parallel,  a  definition  of  integration  should  be 
developed  which  goes  beyond  the  mere  addition  of  data  elements  identified 
by  the  subsystem  model  to  the  main  IDEF1  models. 

A  process  for  detailing  the  authorities  and  responsibilities 
mentioned  above  seems  to  be  a  minimal  first  step.  In  addition,  a  method 
should  be  sought  to  identify  subsets  of  information  which,  like  COBOL 
"working  storage"  elements,  are  internal  to  a  specific  application.  It 
should  be  possible  to  suppress  such  subsets  to  allow  more  focused 
attention  on  the  major  issues  of  the  models.  The  suppression  should,  of 
course,  be  voided  when  the  subsystem  itself  is  under  review. 

The  integration  procedure  should  include  checkable  guidelines  for 
tying  such  subsets  to  the  rest  of  the  model,  for  recognizing  overlaps  in 
the  subsets  of  two  or  more  subsystems  and,  importantly,  for  being  sure 
that  all  the  data  used  by  a  subsystem  is  compatible  with  the  main  IDEF1 
model  even  if  the  representation  is  not  identical  between  the  main  model 
and  the  model  of  the  subsystem. 

At  the  same  time,  work  should  be  undertaken  to  better  define  the 
use  of  IDEF1  in  support  of  the  IDEF0  type  of  integration.  Related 
recommendations  appear  in  the  section  on  IDEF1  procedures. 

4.2.6  Integration  Summary 

The  use  of  the  architectures  for  integration  is  under  way.  Our 
experience  is  now  sufficient  to  point  the  way  to  further  needed 
development.  ICAM  and  other  users  should  build  on  the  lessons  learned  to 
date. 


4.2.7  Other  Uses  of  the  Architectures 


In  ICAM,  the  use  of  the  architectures  has  focused  on  subsystem 
integration.  The  integration  applications  should  not  be  allowed  to 
obscure  the  potential  of  the  architectures  for  such  uses  as: 

•  employee  training 

•  rationalizing  the  documentation  of  procedures 
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•  involving  more  employees  in  system  development 

•  database  design 

More  frequent  use  of  small  models  (ten  to  thirty  diagrams  for 
IDEF0)  of  specific  subjects  would  greatly  facilitate  such  use. 

4.3  Modification  of  Methodologies 

The  lifetime  of  ICAM,  six  years,  has  offered  a  major  opportunity  to 
test,  evaluate,  and  reconsider  the  IDEF  techniques.  The  six-year  span 
covers  a  significant  part  of  the  life  of  IDEF0  and  its  predecessor 
technique.  I0EF1  was  formalized  during  the  ICAM  years.  Both  IDEFp  and 
IDEF1  have  had  significant  use  under  ICAM.  It  is  to  be  expected  that 
experience  with  the  methods  under  ICAM  should  have  suggested  possible 
areas  for  change. 

An  initial  question  which  spans  all  IDEF  methodologies  is  that  of 
quality  assurance.  Is  it  not  time  to  introduce  for  IDEF  methodologies 
the  same  kind  of  control  so  routinely  used  for  other  aspects  of 
industry?  It  is,  of  course,  impossible  to  define  objective  measures  for 
the  application  of  syntaxes  as  simple  as  those  of  IDEF0  and  IDEF1.  The 
same  statement  can  be  made,  however,  about  the  use  of  the  English 
language,  a  subject  in  which  all  of  us  have  been  graded. 

A  user  of  models  would  surely  benefit  if  the  results  were  subjectea 
to  independent  validation  and  verification  as  is  done  with  software.  The 
review  should  be  subject  to  challenge,  but  discussion  of  models  based  on 
quality  concepts  can  only  cause  the  level  of  quality  in  the  mooels 
produced  to  rise. 

The  questions  of  quality  and  of  technology  transfer  are  closely 
related.  The  quality  of  some  IDEF  models  now  being  produced,  and  the 
disappointment  in  many  quarters  with  the  IDEF  methods  seem  to  argue  that 
the  task  of  technology  transfer  has  been  underestimated. 

In  the  software  engineering  discipline  even  experienced  programmers 
expect  to  devote  significant  time  to  learning  a  new  programming 
language.  Perhaps  learning  an  analysis  technique  requires  more  time  than 
the  few  days  now  commonly  allotted  for  IDEF.  In  particular,  some  form  of 
on-going  hand-holding  (or  perhaps  hand  slapping  via  the  quality  function) 
should  be  instituted. 

4.3.1  IDEF0  Methodology  Recommendations 

The  IDEF0  methodology  encompasses:  a  syntax;  the  author/ reader 
cycle;  a  set  of  concepts  such  as  factory  view,  composite  model,  "AS  IS" 
and  "TO  BE";  and  techniques  for  integration.  Each  of  these  is  considered 
separately . 
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The  basic  syntax  has  stood  the  test  of  time  very  well.  Opinion 
still  seems  to  be  split  on  the  use  of  two-way  arrows  but  syntax  is  not  a 
major  cause  of  conflict.  (The  notes  on  quality  assurance  relate  to 
laxness,  not  discord.) 

The  author/reader  cycle  was  developed  in  an  environment  of  limited, 
cohesive  groups  in  a  single  physical  location.  The  ICAM  program  has 
introduced  the  procedure  to  large,  scattered  groups  of  diverse 
character.  The  groups  have,  in  some  cases,  simply  bypassed  the  procedure 
primarily  because  of  the  time  lag  involved  in  circulating  large  model 
kits. 


The  first  need  is  an  absolute  limit  on  the  size  of  kits.  Big  kits 
breed  delays  which  breed  bigger  kits  which  continue  the  spiral.  A  second 
need  is  a  firm  resolve  to  accept  the  implied  resignations  from  the  review 
team  of  evaluators  who  regularly  ignore  or  delay  kits.  Also,  ways  to 
speed  up  the  functioning  of  the  central  library  should  be  explored. 
Allowing  the  kits  to  travel  directly  while  the  library  posts 
after-the-fact  records  would  help.  Electronic  transmission  of  kits  is 
ideal.  Smaller,  project  libraries  might  be  considered. 

These  issues  are  not  central  to  improving  the  application  of  IDEF0, 
however.  The  primary  recommendation  for  IDEF0  is  the  reconsideration  of 
the  definitions  of  composite  models,  "TO  BE"  models  and  of  the  ways  the 
models  relate.  The  original  approaches  were  excellent  first  attempts.  A 
method  which  more  clearly  focuses  on  the  many  existing  similarities  and 
which  allows  for  clear  identification  of  differences  is  needed. 

Certainly,  companies  with  multiple  plants,  products,  or  even  departments 
should  recognize  that  there  probably  is  a  better  way. 

4.3.2  IPEF1  Methodology  Recommendations 

The  IDEFl  methodology  encompasses  the  same  element  types  as  IDEF0 
plus  a  series  of  phases  through  which  a  developing  model  is  to  pass. 

The  IDEFl  syntax  is  essentially  sound,  but  is  open  to  a  minor  and  a 
major  criticism.  A  minor  criticism,  which  is  theoretical,  is  that 
questions  are  left  unanswered:  "What  is  the  name  for  the  graphic 
representation  of  a  relation  class,"  or  "What  rules  govern  the  migration 
of  alternate  key  classes?"  The  major  criticism  is  that  industry 
reviewers  regularly  complain  that  they  cannot  understand  the  models. 

Some  of  this  problem  relates  to  the  training  the  reviewers  have  had,  but 
that  is  not  all.  Model  graphics  are  directed  toward  explicit  guidance  of 
database  managers.  The  graphics  must  be  slanted  toward  verification. 

That  is,  they  must  be  meaningful  to  users.  For  internal  use,  SofTech  is 
evolving  a  more  flexible  set  of  syntax  rules  which  focus  on  users  without 
losing  the  rigor  of  the  existing  syntax.  We  believe  that  some  answers 
already  exist.  Others  could  be  developed  with  reasonable  effort. 

The  comments  about  IDEF0  kits  apply  equally  to  IDEFl.  It  is 
unfortunate  that  IDEFl  literature  actually  encourages  large  kits. 


4-7 


*  m  ’  «  *  ■  *  •  »  '  *  *  ■  ”  •  »  • 


■ 

-  i^l>  uhi*: 


A. 


FTR110410000U 
8  September  1983 


In  the  area  of  composite  models  and  integration,  there  is  serious 
work  to  be  done.  It  is  strange,  for  example,  that  parts  (the  entity 
class  with  Part  Number  as  a  key)  in  MFG1  are  unrelated  to  and  different 
from  parts  in  D£S1.  One  needs  to  examine  relation  classes  and  the 
implied  migration  of  attribute  classes  to  clearly  understand  the 
differences.  The  differences  are  not  those  between  an  engineering  and  a 
manufacturing  bill  of  material.  Our  whole  approach  to  IDEF1  should  be 
geared  to  make  such  discrepancies  almost  impossible  rather  than  very 
common  as  they  actually  are. 

The  circumstances,  under  which  the  display  of  entity  classes  or 
relation  classes  should  be  suppressed,  need  thoughtful  consideration. 

Such  suppression  might  be  appropriate  for:  model  validation,  some  types 
of  model  use,  predefinition  of  scope  for  a  subsystem,  or  compositing  a 
subsystem  model  with  an  overview  model. 

Different  definitions  should  apply  to  "integration"  and 
"compositing"  as  is  true  with  IDEF0. 

For  either  integration  or  compositing,  judgment  by  the  practitioner 
is  required,  but  the  definition  for  each  process  should  provide  greater 
traceability  from  one  model  to  the  other  and  should  channel,  document, 
and  limit  the  use  of  judgment. 

The  concept  of  a  preplanning  phase  and  four  Development  phases 
should  be  reexamined.  Too  many  practitioners  have  never  learned  the 
basic  meanings  of  "entity  class,"  "relation  class,"  "attribute  class," 
and  "key  class."  There  is  a  tendency  to  learn  the  four  development 
phases  one  must  go  through  without  learning  how  the  items  handled  in  each 
phase  fit  together  into  a  unified  syntax  and  semantics.  The  procedure 
seems,  often,  to  replace  the  product  in  our  technology  transfer  methods. 
Questions  about  basic  syntactic  errors  are  too  easily  avoided  with 
answers  like:  "We  haven't  gotten  to  that  yet,  we're  only  at  Phase  three 
and  a  half"  of  the  four  development  phases.  Too  many  discussions  proceed 
without  a  common  understanding  among  those  doing  the  discussing. 

4.3.3  Technology  Transfer 

The  basic  syntactic  elements  or  semantic  elements  of  either  IDEF0 
or  IDEF1  can  be  explained  in  about  fifteen  (15)  minutes.  A  real  grasp  of 
either  method,  however,  requires  practice  under  supervision  so  that  there 
can  be  feedback  on  the  problems  novices  always  encounter.  This  is  the 
big  element  which  must  be  added  to  technology  transfer.  This  is  the 
element  which  the  I0EF1  phases  tend  to  hide.  The  discussion  has  come 
full  circle  to  the  need  for  quality  control. 
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4.4  Recommendations  for  Improvement  of  the  Models 

Most  recommendations  to  be  discussed  for  model  development  are 
grouped  by  model.  The  only  multi-model  recommendation  is  that  MFG1  and 
DfcSl  should  be  reconciled  as  was  mentioned  earlier. 

4.4.1  IDEF0  Model  of  Manufacture  (MFG0) 

MFG0  is  the  oldest  and  most  tested  of  the  ICAM  models.  It  provides 
a  good  basis  for  models  of  other  industries.  A  few  points  are  worth 
noting: 

•  The  model  should  give  more  understanding  of  the  details  of  a 
function  rather  than  itemizing  all  of  the  types  of  subject 
items  to  which  the  function  might  apply; 

•  Some  of  the  interfaces  should  be  examined  carefully  to 
satisfy  the  user  that  the  interface  arrows  fully  support  the 
function  identified  by  the  box  title; 

•  Cross  reference  models  from  other  viewpoints  would  be  useful 

4.4.2  XDEF0  Model  of  Design  (DES0) 

DES0  models  the  administration  of  the  design  process  to  a  greater 
degree  than  it  models  the  technical  problems  of  that  process.  For 
example,  it  considers  the  level  of  design  (preliminary  vs.  detail).  It 
does  not  describe  the  technical  decisions  which  must  be  made  to  progress 
from  one  level  to  the  other.  In  fact,  the  end  product  being  designed 
could  be  almost  anything.  The  utility  of  this  approach  depends  on  the 
user's  objectives. 

If  a  user  wishes  to  build  computer  aids  for  the  task  of 
administering  design  (assigning  people,  tracking  progress  etc.),  the 
model  provides  a  good  basis  for  further  work.  If  the  user  wishes  to 
build  computer  aids  for  specific  design  tasks,  or  for  configuration 
control,  another  viewpoint  is  needed.  That  is,  a  number  of  small  models 
of  different  design  tasks  should  be  built. 

The  general  recommendations  which  were  given  for  MFG0  also  apply  to 

DES0. 

4.4.3  IDEF1  Model  of  Design  (DES1) 

DES1,  like  DES0,  is  concerned  primarily  with  the  administrative 
side  of  design.  That  is,  the  information  identified  tends  to  be 
information  about  the  status,  or  source  of  approval  for  each  part  of  the 
design  rather  than  information  which  constitutes  the  design  itself. 
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Under  these  circumstances,  it  is  especially  important  to 
differentiate  positively  between  information  and  information  about  the 
carrier  of  the  information.  For  example,  maintainers  of  the  model  should 
note  that  "parts  list  item"  (EC  118)  and  "next  assembly  use  item"  (EC119) 
both  document  the  inclusion  of  part  A  in  assembly  B.  That  is,  they  are 
the  same  thing  even  though  they  appear  on  different  documents. 

Since,  as  noted  earlier,  DES1  should  be  reconciled  with  MFG1,  most 
of  the  comments  about  that  model  apply  equally  to  DES1. 

4.4.4  IDEF1  Model  of  Manufacturing  (MFG1) 

The  first  priority  for  anyone  maintaining  or  using  MFG1  should  be 
the  populating  of  entity  classes  with  attribute  classes.  This  step  would 
have  the  direct  value  of  greatly  increasing  the  data  content  of  the 
model.  It  will  have  a  greater  value  of  improving  the  structure  of  the 
model  which  justifies  postponing  the  adding  of  further  entity  classes 
until  the  attribute  class  additions  are  completed.  The  addition  of 
attribute  classes,  if  done  with  care,  would  alter  the  structure  of  the 
model. 


The  ultimate  definition  of  any  entity  class  lies  in  the  attribute 
classes  of  which  it  is  composed.  Completing  those  definitions  of  the 
existing  entity  classes  (by  adding  attribute  classes)  and  then  carefully 
examining  the  model  will  quickly  eliminate  many  oversights  which  easily 
escape  detection  in  the  current  state  of  the  model. 

Some  examples  are  necessary  to  understand  why  this  is  true.  A  copy 
of  the  model  would  be  helpful  in  reviewing  the  discussion. 

One  case  where  some  attribute  classes  are  available  is  Entity  Class 
414  "Drawing."  One  of  the  attribute  classes  listed  is  "Drawing  Bill  of 
Material."  This  attribute  class  is  defined  as  "the  structured  alpha 
numeric  matrix  that  identifies  all  the  component  details  or  dependent 
materials  which  comprise  the  part  as  defined  by  the  engineering 
drawing."  It  happens  that  a  matrix  represents  a  forbidden  repeating 
attribute,  but  that  is  not  the  issue.  The  attribute  clearly  concerns  the 
part,  not  the  drawing.  In  this  case,  it  is  easy  to  identify  a  confusion 
between  the  entity  and  the  carrier  of  the  information  about  the  entity. 

As  in  DES1,  information  about  a  part  (EC  6)  has  been  confused  with 
information  about  the  drawing  which  only  carries  the  information  about 
the  part . 

In  this  instance,  the  mere  presence  of  the  attribute  class  is  not 
enough  to  prevent  error.  But  without  the  attribute  classes,  reviews  of 
the  model  do  not  offer  the  basis  for  this  kind  of  analysis. 

It  happens  that  Entity  Class  414,  "Drawing"  is  part  of  the 
illustration  of  another  problem  which  the  addition  of  more  attribute 
classes  would  help  to  eliminate.  The  model  shows  that  an  Engineering 
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The  resolution  via  entity  class  12  is  intuitively  comfortable. 
Again,  the  addition  of  the  relevant  attribute  classes  would  make  the 
situation  clearer.  The  reviewer  must  ask,  "What  are  the  attributes  of 
the  'Drawing'  and  what  other  attributes  relate  to  the  'Released 
Engineering  Drawing'?"  The  syntax  of  IDEF1  requires  that  entity  classes 
may  share  only  the  attribute  classes  which  are  key  to  one  of  them,  in 
this  case  the  drawing  number. 

On  this  basis,  it  is  easy  to  conclude  that  the  valid  attribute 
classes  of  Released  Engineering  Drawing  (EC  12)  are  the  key  classes  of 
Drawing  (EC  414)  and  Engineering  Release  (EC  69)  and  no  others.  Since 
the  entity  classes  are  generally  unpopulated,  the  accuracy  of  the 
conclusion  can  only  be  a  matter  for  speculation.  In  this  case,  it  seems 
likely  that  a  change  of  name  for  Entity  Class  12  to  "Release  of  Drawing" 
would  more  accurately  guide  our  intuition  —  it  is  the  fact  of  the 
release,  not  the  drawing  which  should  resolve  the  m-n  relation  class. 

But,  as  suggested  above,  discussion  at  this  length  would  be  impossible 
and  unnecessary  if  the  attribute  classes  were  available  on  which  to 
settle  the  matter. 

The  change  of  entity  class  name  just  proposed  illustrates  a  second 
recommendation  for  MFG1.  For  many  entity  classes,  a  name  reflecting  an 
event,  a  relationship  or  a  reference  would  be  more  descriptive  than  a 
name  reflecting  a  thing  such  as  "Released  Engineering  Drawing."  Examples 
of  the  proposed  types  of  name  include: 

•  Event  -  release  of  drawing 

•  Relationship  -  assignment  (of  employee  to  project) 

•  Reference  -  callout  (of  a  tool  by  a  process  step). 

Figure  4-2  shows  the  entity  classes  of  Figure  4-1  renamed  according 
to  this  recommendation. 

Figure  4-2  is  not  a  recommended  form  of  the  model.  Hopefully,  it 
illustrates  that  further  changes  in  these  structure  of  the  model  are 
needed. 

The  names  of  Entity  classes  181  and  189  are  strained.  The 
existence  of  such  entity  classes  must  be  questioned.  Also,  it  seems  more 
likely  that  a  drawing,  rather  than  only  one  of  several  releases  of  that 
drawing,  "defines"  a  part.  In  addition,  one  might  want  to  rename  (or 
delete)  several  of  the  other  attribute  classes. 

Actual  resolution  of  the  questions  raised  will  require  careful 
analysis  based  on  the  two  recommendations  offered: 


4-12 


It 


|j^g 


IS  CALLED 
OUT  AS 


DRAWINC 


FTR110410000U 
8  September  1983 
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To  repeat: 


All  entity  classes  should  be  fully  populated  with  attribute 
classes  and  the  model  should  be  reviewed  on  the  basis  of  the 
attribute  classes  defined; 

Entity  classes  which  appear  to  resolve  m-n  relation  classes 
should  be  candidates  for  renaming,  often  on  the  basis  that 
they  refer  to  events,  relationships,  or  references  rather 
than  to  things. 
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SECTION  5 

REFERENCE  MATERIAL 

5.1  Abstracts  of  Interim  Technical  Reports 

The  following  Interim  Technical  Reports  have  been  produced  on  this 
program. 

5.1.1  List  of  Interim  Reports 

1.  Interim  Technical  Report  ITR110410001U,  "ICAM  Architecture, 
Part  III,"  April,  1981  (Period  01  October  1981  -  30  March 
1982) 

Appendix  Page 

A  MCDG  INTEGRATION  RESULTS  A-l 

B  OES0  DEFICIENCIES  B-l 

C  SUBSYSTEM  5501  (IPS)  and  6201  (ICENT 

SCOPING  RESULTS  C-l 

D  GLOSSARY  DEFINITIONS  D-l 

E  MFG0  DEFICIENCIES  E-l 

F  ARROW  TRACE  PROCEDURE  F-l 

H  MFG01  COMMON  GLOSSARY  PAGE  FORMAT  H-l 

I  MAINTENANCE  PROCEDURE  1-1 

J  MCMM1  ANALYSIS  REPORT  3-1 

K  MFG1  PRIORITIZED  RECOMMENDATION  K-l 

L  DES1  -  PHASE  ZERO  SCOPE  AND  CONTENTS  - 

AUTHOR  CONVENTIONS  L-l 

M  DES1  -  PHASE  TWO  ENTITY  CLASS  DIAGRAMS  M-l 

N  DES1  -  ATTRIBUTE  CLASS  POOL  -  PHASE  THREE  N-l 

2.  Interim  Technical  Report  ITR110310002U,  "ICAM  Architecture, 
Part  III,  July,  1981  (Period  01  April  1981  -  30  June  1981) 

Appendix  Page 

A  DES1  PHASE  III  DIAGRAMS  A-l 


5-1 


FTR110410000U 
8  September  1983 


m 


3. 


4. 


5. 


6. 


7. 


Interim  Technical  Report  ITR110410003U,  "ICAM  Architecture, 
Part  III,"  October,  1981  (Period  01  July  1981  -  3  0 


September  1981) 

Appendix  Page 

A  MFG01  COMMON  GLOSSARY  FORMAT  ALTERNATIVES  A-l 

B  KIT  X  MFG0  GLOSSARY  AND  ARROW  TRACE  B-l 

C  DES1  FINAL  REPORT  C-l 

D  EXECUTIVE  OVERVIEW  D-l 

E  TRAIN  THE  TRAINERS  E-l 

F  RECOMMENDED  WORK  TO  BE  PERFORMED  F-l 


Interim  Technical  Report  IRT110410004U,  "ICAM  Architecture, 
Part  III,"  January,  1982  (Period  01  October  1981  -  31 
December  1981) 

Appendix  Page 

A  SHORTENED  IDEF0  INTEGRATION  PROCEDURE  A-l 

B  A  PROCEDURE  FOR  COMPOSITION/INTEGRATING  IDEF1 

INFORMATION  MODELS  (DRAFT)  B-l 

Interim  Technical  Report  ITR110410005U,  "ICAM  Architecture, 
Part  III,"  April,  1982  (Period  01  January  1982  -  31  March 
1982) 

Appendix  Page 

A  5501/6201  INTEGRATED  COMPOSITE  VIEW  A-l 

Interim  Technical  Report  ITR110410006U,  "ICAM  Architecture, 
Part  III,"  July,  1982  (Period  01  April  1982  -  30  June  1982) 

Appendix  Page 

A  INDUSTRY  REVIEW,  WPAFB,  Dayton,  Ohio 

(8-10  June)  REVIEWERS  COMMENTS  A-l 


Interim  Technical  Report  ITR110310007U,  "ICAM  Architecture, 
Part  III,"  February,  1983  (Period  01  July  1982  -  31  October 
1982) 

Appendix  Page 
A  "AS  IS"  QA01/MFG01  INTEGRATION  A-l 
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MFG01  FEO  REQUIREMENT 

B-l 

C 

MFG01  HIERARCHY 

C-l 

5.1.2  Interim  Technical  Report,  Document  Request  Order  Form 
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